NYSE arca Trader Update 


Pillar Gateway — Frequently Asked Questions 


General Configuration & Processing 


1. 


Question: Which session level configurations can | set up as defaults that will be persisted day to 
day? If | make an intraday change via the Session Configuration Request (binary) or Logon Profile 
(FIX), how long does it take the settings to update and for how long are those changes 
persisted? 


Answer: The Pillar Gateway Certification Session Request Form and Production Session Request 
Form allow the firm to select certain session level default configurations that are persisted from 


day to day. 





If the firm makes an intraday change to any of these settings via the gateway, the new settings 
are applied after a Session Configuration Acknowledgement (binary) or Logon Response (FIX) is 
generated. These updated settings will be persisted for that trading day only (or until the next 
time Pillar restarts, in the event of an intraday session restart). During the trading day, the 
updated settings are persisted even if the user logs out and logs back in. 


To make changes to the overnight defaults, the firm must contact NYSE Group Support with this 
request. 


It is recommended each time they disconnect and reconnect, that the firm refer to the latest 
Session Configuration Acknowledgement message on the REF or GT stream (binary) or the Logon 
Session Profile in the Logon Response message (FIX) to confirm the current settings. 


Question: Can | trade all symbols on the connected market from any of my gateway sessions? 


Answer: For NYSE Arca Equities, each Pillar Gateway session will have access to all symbols. 
There is no symbol migration period — the symbols will be immediately available from the new 
Pillar Gateways, and simultaneously from the legacy UGW gateways during the parallel period. 


Question: How do | send a certain kind of order type? 


Answer: FIX and Binary order validation spreadsheets indicating how to send each supported 
order type are provided along with the Pillar Gateway certification scripts. To request these 
materials, please contact Firm Testing at firmtesting@nyse.com or 212-896-2830, x2, option 2. 


Question: Can you give an example of Cancel/Replace and Modify order chaining in the Pillar 
Gateway? 


Answer: If accepted, both Cancel/Replace and Modify requests update the ClOrdID of the open 
order to the ClOrdlD of the request. This is true for both the Pillar FIX and Binary protocols. 


For example, a new order is entered with ClOrdID-1. Then, a Cancel/Replace request to change 
the limit price of that order is entered with ClOrdID-2 and OrigClOrd|ID-1. A subsequent Modify 
request to reduce the quantity of that order would then be entered with ClOrdID-3 and 
OrigClOrdID-2. Any further actions on the order (whether Cancel/Replace, Modify, or Cancel) 
would refer to it with OrigClOrdID-3, and so forth. 


The difference is that a cancel/replaced order gets a new OrderID (published to XDP) and loses 
its ranking on the order book, while a modified order retains its old OrderID and maintains its 
ranking on the order book. 


Binary Protocol — SeqMsgliD & FIX Drop Copy 


5. Question: Pillar Binary Gateway strictly enforces that the “seq” portion (sequence number) of 
the SeqMsgID increases by one with each new message written to the TG stream. If my client 
side application sequence number gets out of sync and is higher than what Pillar expects, how 
can | increase the TG stream next expected sequence number without sending business 
messages? 


Answer: Send Sequenced Filler Messages. Each one sent will increase the TG stream’s next 
expected sequence number by 1. 


6. Question: The Pillar Gateway Binary spec, FIX Drop Copies section, mentions that a 
hexadecimal/base 16 representation of SeqMsglD is used to populate the ExecID (17) and 
ExecRefID (19) tags in FIX drop copy messages for those transactions. Can you give an example? 


Answer: The FIX tags will be populated with the hexadecimal string representation of the 128- 
bit SeqMsgID from the corresponding binary message delivered on the GT stream. 











Example: 
Decimal Hexadecimal Wire Format 
Format Format (Little Endian) 
SeqMsgld.StreamID.sess = 167773517 OxA00054D 4D05000A 
SeqMsgld.StreamID.value = 218735618 OxDO9A402 02A4090D 
SeqMsgld.seq = 1234567 0x12D687 87D6120000000000 




















Full 128-bit hexadecimal string = OxO0A00054D0D09A402000000000012D687 


Value sent to FIX drop copy = A00054D0D09A402000000000012D687 


Binary Protocol — Reference Data 


7. 


10. 


11. 


Question: Why are reference data messages (e.g. Equities Symbol, MPID, Session Configuration, 
etc.) published to both the GT and REF streams? 


Answer: The REF stream has reference data because any change to that data is reflected as a 
new message in the streams and it is quicker to recover the REF stream as there are fewer 
messages compared to GT. 


The same messages are also published to the GT stream to make the stream complete with 
reference data as well as order related messages so that the data can be interpreted and 
stitched together without changing streams. 


Question: The specification indicates that the firm should read request all the queued messages 
on their GT or REF streams at start of day. If | specify a very large number as the end range, how 
do | tell when | have drained the entire queue of messages? 


Answer: The StreamAvail message (published every second) will indicate the next available 
sequence number on the stream. When the number of drained messages = the next available 
sequence number — 1, all messages have been delivered. 


Question: | understand that the SymbollD integer values used in the Pillar Binary gateway match 
the SymbollDs used in XDP market data. If | am currently an XDP market data subscriber and use 
the nightly symbol index mapping XML file, do | need to read the Equities Symbol Reference 
Data messages provided in my gateway REF and GT streams on a daily basis? 


Answer: It is recommended that firms read the reference data messages provided in the 
gateway for a couple of reasons. First, the XML symbol file only provides the mapping between 
ticker symbol and SymbollD whereas the Equities Symbol Reference Data message provides 
additional information such as max order price, round lot size, listed market, etc. 


Second, it ensures that the firm will get the latest data in the unlikely event that 
changes/corrections occur to the symbol reference data after the previous night’s XML file was 
published, or a symbol is added intraday. 

Question: Do SymbollDs ever change for a security? 

Answer: SymbollDs generally do not change for a given security, except for certain corporate 


actions that are applied the night before the action takes effect. 


Question: What is the business purpose of the Minimum Price Variant (MPV) Class and Level 
reference data | receive in my REF and GT streams at start of day? 


Answer: For NYSE Arca Equities, each of 5 classes corresponds to a Tick Pilot group. The Class 
message provides the Retail Price Improvement order type MPV and the Limit Up/Limit Down 
(LULD) MPV for the security. 


Each class has a corresponding Level message as well, containing various price levels as 
applicable. Each level has a “Price” field which describes a limit price range for order entry. For 
example, Price “0.00” refers to the limit price level between $0.00 and less than $1.00. Price 
“1.00” refers to the price level equal to or greater than $1.00. The “Quoting MPV” field for each 
price level governs limit price validation for orders entered within that price range. 


Binary Protocol — Other 


12. Question: Can | set a session level default configuration for Throttle Preference (queue orders or 
reject orders when throttled)? 


Answer: No, there is no default for this setting and it is not persisted once a stream is closed. 
Instead, throttle preference must be specified in the Pillar Stream Protocol when opening a TG 
stream via the “Open” request message. Once the stream is open, the setting may then be 
changed intraday by sending a Session Configuration Request. This is designed to provide the 
firm with full intraday control over throttle handling. For more details, see the “Session 
Configuration Request/Acknowledgment” sections of the Pillar Gateway Binary Protocol 
Specification. 


13. Question: How do | calculate and populate the various “length” fields in variable length 
messages? 


Answer: Variable length messages can contain more than one payload, each of which has its 
own MsgHeader. 


- Each instance of a “MsgHeader” contains a “length” field which must be populated with the 
sum of that MsgHeader itself + all message payload/add-ons that follow that header 


- Each variable length message has a “minimum length” specified in the “MsgHeader” field of 
the first payload 


- Throughout the specification, optional add-on fields are shown as a minimum of 4 bytes in 
the field, because every add-on begins with a 4 byte MsgHeader. If not intending to send an 
add-on, the firm should not populate these bytes. Instead, send only the preceding fields 
that add up to the minimum length 


- Example A — Total message length, New Order Single/Cancel Replace Request without any 
add-ons = 73 bytes 


- Example B — Total message length, New Order Single/Cancel Replace Request with the 
OptionalOrderAddOn - Equities Customer = 114 bytes 


14. Question: The specification indicates that if | send a New Order Single/Cancel-Replace Request 
with the OptionalOrderAddOn - Equities Customer, it will only be returned on the Order Ack and 
not on any other message types (i.e. not echoed back on the Execution Report or Cancel/Cancel- 
Replace/Modify Reject and UROUT). Why is this? 


Answer: Correct. This is because the Equities Customer add-on simply includes additional order 
attributes. In keeping with the philosophy of this binary protocol to keep GT stream order 
activity messages as efficient as possible, order attributes are returned on the initial Order Ack 
but not subsequent activity. 
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